Reporting for multi-user services in wireless networks

ABSTRACT

A method and system for adapting multi-user multimedia data in a communication system with a server providing the multi-user multimedia data to clients and with an intermediate network part. The intermediate network part is arranged to provide information on communication between the server and the clients. The server sends multimedia data to the clients. Distribution characteristics are determined for the clients, which are considered by the generation of an aggregated feedback report on the clients&#39; reception conditions of the multimedia data in the intermediate network part. The feedback report includes additional information about aggregation fashion. The aggregated feedback report is sent to the server in order for the server to adapt the transmission of the multimedia data from the server to the clients according to the aggregated feedback report.

TECHNICAL FIELD OF THE INVENTION BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to communications networks andin particular, to a method for adapting multi-user multimedia data in acommunication system.

2. Description of Related Art Including Information Disclosed Under 37CFR 1.97 and 1.98

Universal Mobile Telecommunication System UMTS is being developed tooffer wireless wideband multimedia service using Internet protocol. TheUMTS as a third-generation 3G mobile communication combines streamingwith a range of unique services, like for example geographicalpositioning, to provide high-quality Internet content to the users.Images, voice, audio and video content are example of mobile multimediaservices, which are delivered to the users via media streaming anddownload techniques. It means once the content has been put onto a mediaserver, it can be delivered on-demand via download or streaming. Todownload content, the user clicks on a link and waits for the content tobe downloaded and playback to begin. Download capabilities are easy tointegrate since the hypertext transfer protocol (HTTP) can be used fordownloading files. To access streaming data or general speakingmultimedia data, the user clicks on a link to start playback, which isalmost immediate. Because streaming is a semi-real time service thatreceives and plays back data at the same time, it puts greater demandson protocols and service implementation, especially when the service isto work over networks with little or no quality of service, like this isthe case in UMTS. The radio resources, which are used on the last partof a transmission is to be used in a better way.

Currently work is being done to introduce broadcasting and multicastinginto WCDMA and GSM wireless networks. Both broadcast and multicastprovide transport efficiency and reduce the load on the content servers,like for example the streaming servers. Additionally solutions are beingworked out for performing streaming or general formulated multimediatransmission in a wireless network. In the following the correspondingarchitectures are presented.

The FIG. 1 shows the current so-called Multimedia Broadcast/MulticastService (MBMS) architecture. In the following merely the most importantnodes and examples of the different access networks, like UTRAN, GERAN,connecting the end user UE are mentioned. The access networks arehandled by means of a serving node, SGSN that communicates with an edgenode, the GGSN that is responsible for connection to the externalnetworks, like Internet. The BM-SC entity connected to GGSN isresponsible for the provision of multicast/broadcast, like for examplefor bearer establishment and data forwarding. BM-SC offers interfaces toa content provider, so that said content provider can request datadelivery to the users. The BM-SC may authorise and charge contentproviders.

In order to keep the solution simply, it is foreseen currently on theradio network part to support only a downlink channel for data trafficgoing to the end user UE. It means there is no uplink channel in anaccess network, which can be used by the end users UE to send forexample reports regarding the quality of receiving.

The transmission of the multimedia flow for a single user is performedin a wireless network by means of a Packet Switched Streamingarchitecture. Said architecture is depicted in FIG. 2. It showsstreaming client being connected via an access network, like UTRAN orGERAN with an UMTS Core network. In the UMTS two important kind of nodesare depicted, SGSN and GGSN. The SGSN is a serving node for handling theto the access networks attached users. The GGSN is responsible forconnection to the external networks, like IP Network. For the purpose ofmultimedia provision there are different entities in the IP network,like content server being responsible for providing multimedia data.

The multimedia data is distributed by means of multimedia protocols. TheFIG. 3 shows a protocol stack with the protocol layers responsible formultimedia transmission, Real-time Transport Protocol RTP. The RTP usesUniversal Datagram Protocol UDP as a transport protocol appropriate fortransmission of streaming data, because UDP provides a fast transmissionalthough not reliable like it is the case by Transmission ControlProtocol TCP. HTTP and Real-Time Streaming Protocol RTSP run over thereliable TCP. The RTSP provides session control for streaming sessions.HTTP is used for transmission of still images, bitmap graphics and text.

The RTP provides end-to-end network transport functions suitable forapplications transmitting real-time data, such as audio, video orsimulation data, over multicast or unicast network services. Thefunctions provided by RTP include payload type identification, sequencenumbering, timestamping, and delivery monitoring. The RTP contains arelated RTP Control Protocol RTCP augmenting the data transport, whichis used to monitor the QoS and to convey information about theparticipants in an ongoing session. Each media stream in a conference istransmitted as a separate RTP session with a separate RTCP stream.

RTP adds a time stamp and a sequence number to each UDP packet in aspecial RTP header. The time stamp is related to the sampling or thepresentation or composition time of the media carried in the payload ofthe RTP packet. It is used for playing back media at the correct speed,and together with RTCP, it is used for synchronizing the presentation ofother streaming media. A payload specification defines theinterpretation of the time stamp and other RTP fields. The recipientuses the sequence number to detect the loss of packets statistics onloss can be reported to the server by means of RTCP.

RTCP reports provide statistics about the data received from aparticular source, such as the number of packets lost since the previousreport, the cumulative number of packets lost, the interarrival jitter,etc. An additional draft defines a format for extensions to the RTCPsender and receiver reports. A detailed description of RTCP can be foundin RFC 1889, Chapter 6. The RTCP control protocol is based on theperiodic transmission of control packets to all participants in thesession, using the same distribution mechanism as the data packets. Theunderlying protocol must provide multiplexing of the data and controlpackets, for example using separate port numbers with UDP.

The primary function of RTCP is to provide feedback on the quality ofthe data distribution. This is an integral part of the RTP's role as atransport protocol and is related to the flow and congestion controlfunctions of other transport protocols. The feedback may be directlyuseful to diagnose faults in the distribution. Sending receptionfeedback reports to all participants allows one who is observingproblems to evaluate whether those problems are local or global. With adistribution mechanism like IP multicast, it is also possible for anentity such as a network service provider who is not involved in thesession to receive the feedback information and act as a third-partymonitor to diagnose network problems. This feedback function isperformed by the RTCP sender and receiver reports. The RTCPspecification requires that all participants send RTCP packets,therefore the rate must be controlled in order for RTP to scale up to alarge number of participants. By having each participant sending itscontrol packets to all the others, each can independently observe thenumber of participants. This number is used to calculate the rate atwhich the packets are sent.

Furthermore the RTCP has an optional function to convey minimal sessioncontrol information, for example participant identification to bedisplayed in the user interface. This is most likely to be useful insessions where participants enter and leave without membership controlor parameter negotiation. RTCP serves as a convenient channel to reachall the participants, but it is not necessarily expected to support allthe control communication requirements of an application. A higher-levelsession control protocol, which is beyond the scope of this document,may be needed.

The above described functions, besides the last one being optional, aremandatory when RTP is used in the IP multicast environment and arerecommended for all environments.

Therefore the multimedia service in wireless network is to be used aswell for a single user, the so-called unicast connections but all abovefor a group of users, the so-called point-to-multipoint or evenmultipoint-to-multipoint connections. The point-to-multipoint servicesrequire high demands on the network infrastructure and consumeconsiderable amounts of bandwidth. Some examples of such services arevideo-conferencing, whiteboarding, real-time multi-user games,multimedia messaging, virtual worlds. This kind of multimediaapplications uses for transport broadcast or multicast mode. Broadcasthas the possibility of addressing a packet to all destinations by usinga special code in the address field. When a packet with this code istransmitted, it is received and processed by every user on the network.This mode of operation is called broadcasting. Multicasting supportstransmission to a subset of the users. Each can register to a multicastgroup. When a packet is sent to a certain group, it is delivered to allusers registered to that group.

The RTCP has mechanisms for reporting in case of multicast sessions.However, in case of radio networks the multicast reporting waste airinterface resources and potentially overloads the network servers.Furthermore, in the preferred multicast solution there is only adownlink and no uplink channel. This implies that the users cannot sendRTCP reports to the source.

In RFC 1889 there is an entity, the so-called mixer introduced. Themixer receives RTP packets from one or more sources, possibly changesthe data format, combines the packets in some manner and then forwards anew RTP packet. Since the timing among multiple input sources will notgenerally be synchronized, the mixer will make timing adjustments amongthe streams and generate its own timing for the combined stream. Thus,all data packets originating from a mixer will be identified as havingthe mixer as their synchronization source. Therefore the mixer creates anew message being a combination of the received messages.

However, for the current RTP the use of RTCP receiver reports ismandatory in multicast sessions. In particular it is important that themulticast sender receives these reports to signal that clients are stilllisting. The current revision of the RTP provides a feature to suppressRTCP receiver report usage. However, by omitting RTCP receiver reportsalso an important means of getting quality feedback from the receiversis omitted. The source cannot adapt to changing conditions and alsocannot provide alternative streams.

It is anyhow questionable what the source should do if an RTCP reportfrom a single client indicates that several RTP frames were corrupted orlost and that client would better be served with a lower data rate. Thisis especially a big question mark in wireless networks with increasinglyheterogeneous users. The multimedia users are characterized by a varietyof mobile terminals with a wide range of display sizes and capabilities.In current multicast solutions the source will either ignore suchreports or adapt to the slowest receiver. Both are not adequate whenclients are charged for the service and the bearer that is used for theservice. In addition different radio-access networks make multiplemaximum-access link speeds available. Because of the physicalcharacteristics of cellular radio networks, the quality and, thus, thedata rate of ongoing connection will also vary, contributing to theheterogeneity problem.

Therefore the following problems occur regarding the RTCP reporting inmulticast sessions in wireless networks. The scarce radio resources areused inefficient, when every user sends a RTCP report. This can alsoleads to overload of servers, like RNC, SGSN, GGSN, for example in casethe reports are generated by a high number of users, for example in afootball arena. Because of the heterogeneous networks the source mustadapt to slowest user. Further because of the higher number of reportsand the long time needed for evaluation of the reports a long delay isgenerated before the source is aware of a problem. Further the RTCPreports do not contain all necessary information for wireless networks

SUMMARY AND DESCRIPTION OF THE INVENTION

It is an object of the present invention to provide a solution for anefficient utilization of a radio interface for multi-user multimediaservices in wireless network.

The basic idea is to adapt multi-user multimedia data in a communicationsystem with a server providing the multi-user multimedia data to clientsand with an intermediate network part. Said intermediate network part isarranged to provide information on communication between the server andthe clients. The server sends multimedia data to the clients. For theclients distribution characteristics are determined, which areconsidered by generation of aggregated feedback report on the clients'reception conditions of the multimedia data in the intermediate networkpart. Said feedback report includes additional information aboutaggregation fashion. Said aggregated feedback report is sent to theserver in order the server adapts the transmission of the multimediadata from the server to the clients according to the aggregated feedbackreport.

An advantage of the invention is the provision of efficient utilisationof scarce and expensive network resources in wireless networks, inparticular on the uplink direction. With the present invention isachieved that the radio resources are utilised in a better way becausethe report are relevant for more then one user. In case of one user thesource needs to perform a lot of reporting analyses in case of largeuser sessions. This is especially a waste of resources if the memberscan be grouped into one or a few access networks with very similarcharacteristics and behavior. Furthermore this will reduce the load andthe complexity in the source. This solution provides the only way ofreporting in case no uplink channel is available, as in the broadcastsolution. Besides the aggregated RTCP report can consider allinformation in the cell, rather than a single dedicated RTCP report perclient. For example in case of almost overload situations, the RNC knowsthis before congestion is encountered by loosing frames and can reportthis to the source for all clients in the same cell. This would improvethe quality experience for the end-user. Furthermore in general thereporting is faster since the air-interface delay is skipped. This isvery much the same as for the single-user multimedia case.

In one embodiment of the present invention the distributioncharacteristics are related to a geographical area including a group ofclients. One or more cells as defined in a wireless communicationnetwork can build the geographical area.

In another embodiment the distribution characteristics are related to adetermined multicast group structure, which can include clients havingdevices for receiving data transmitted with high or with low speed.

In a preferred embodiment the distribution characteristics are relatedto information received from a radio resource management. The radioresource management has the actual information about the currenttransmission performance on the radio interface. Therefore it ispreferable to consider this information in the generation of thefeedback report.

The interaction between the intermediate node and the radio resourcemanagement can be performed either frequently or event-based.

In another embodiment the distribution characteristics are related toinformation received from the clients. In order to improve the qualityof the aggregated feedback report the clients sends their own reports.The advantage of this solution is that the aggregated feedback reportsinclude information that can not be determined from the distributioncharacteristics being derived form the radio layers.

It is proposed that the information received from the clients is senteither frequently or event-based, when for example an extraordinaryevent occurs.

It is preferable that feedback reports from the clients are suppressedin the client terminals. The advantage of this embodiment is that notraffic is produced on the uplink link so that radio resources aresaved. In particular in case no uplink channel is available this is apreferable solution.

Further it is advantageous to receive information from the radioresource management, which has the actual information about the currentradio resource availability and from the clients and to combine theinformation in order to generate a more adequate feedback report to theserver.

In a preferred embodiment of the present invention the additionalinformation about aggregation fashion includes a number of clients towhom the aggregated feedback report applies so that the server candistinguish when a report applies to one client or to a group ofclients. According to this information one can decide on a proper actionfor example whether an adaptation is useful or whether a replication ofthe actual stream is more suitable.

In another preferred embodiment of the present invention the additionalinformation about aggregation fashion comprises radio characteristics ofan access network in which the clients are. Having this information theserver can distinguish how to adapt the multimedia flow considering thespecific characteristics of different access networks.

It is proposed that the aggregated feedback report includes alsoinformation for the server about the adaptation manner. Thus, the serverreceives additional information for better judgment how the streamcould/should be adapted.

It is preferably that a negotiation on the frequency of feedback reportsfrom the clients and/or from the radio resource management to theintermediate node is performed. This can be either in fixed intervals orevent-based, it means when a certain circumstances occur.

In an advantageous embodiment the clients refrain from sending feedbackreports to other clients receiving the data stream so that the anonymityof the multimedia clients to whom the multimedia data is to be multicastis guaranteed.

In a preferred embodiment of the present invention the generatedaggregated feedback report includes a fraction of lost packets providedby the intermediate node depending on the current conditions ofdelivery. This fraction can be for example a highest sequence number theintermediate node has received or an interarrival jitter provided by theintermediate node.

It is proposed that the server receiving the aggregated feedback reportacts in a proper manner. For example the server adapts accordingly afterthe information included in the report considering the percentage of theclients for which said feedback applies is utilized. The reaction can beto announce a new channel to the clients or to adapt the stream, forexample to reduce bit-rate or to switch to more reliable codec.

Further it is proposed to implement the functionality of theintermediate network part in the same network part. In the alternativesolution it is proposed to split the functionality between differentnodes forming the intermediate network part.

An embodiment of the present invention is based on the Real-timeTransport Protocol RTP having a control protocol Real-time TransportControl Protocol RTCP for reporting feedback. However the presentinvention should not be restricted to this example of multimediaprotocols.

Furthermore the present invention discloses an intermediate network partadapted to perform an adaptation of multi-user multimedia data in acommunication system with a server providing the multi-user multimediadata to clients. The intermediate network part is arranged to provideinformation on communication between the server and the clients. Itincludes means for forwarding multimedia data from the server to theclients. Means for determination of distribution characteristicsassociated with the clients is also part of the intermediate networkpart. The task of said means is to determine for example from the radioresource management having access to the lower layers the transmissionconditions, on which the multimedia is transmitted to the clients.

Further the intermediate network part node has means for generating anaggregated feedback report on the clients' reception conditions of themultimedia data considering distribution characteristics, wherein saidfeedback reports include additional information about the aggregationfashion. In this manner generated feedback report is sent to the serverby means for sending the aggregated feedback report.

It is proposed that the means of the intermediate network part areimplemented in the same network node. Alternatively it is proposed thatthe means for determining of distribution characteristics associatedwith the clients and the means for generating an aggregated feedbackreport are split between different nodes. In the last case it isrequired to provide means for receiving the external determineddistribution characteristics associated with the clients.

In the following a detailed description of the invention is given.

FIG. 1: Broadcast/Multicast Service (MBMS) architecture.

FIG. 2: Packet Switched Streaming (PSS) architecture.

FIG. 3: Protocol stack with the protocols layers for streamingtransmission.

FIG. 4: Protocol model for the present invention.

FIG. 5: Embodiment of the present invention for determining ofdistribution characteristics associated with the clients.

FIG. 6: Embodiment of the present invention for generation of anaggregated feedback report per mobile terminal.

FIG. 7: Embodiment of the present invention for generation of anaggregated feedback report per cell.

In the following the present invention is explained in respect to awireless network using the RTP. The terms intermediate node andintermediate network part are used as synonyms.

The basic idea is to have an intermediate network part in the wirelessnetwork taking care of an aggregated RTCP reporting, rather than thateach user individual performs its own reports. The term intermediatenetwork part describes a functionality, which can be implemented in onenode, in the following described as intermediate node or thefunctionality can be split between different network nodes.

The aggregated RTCP reporting or general one feedback report for exampleper multicast group is generated. A real time determination ofdistribution characteristics is performed considering cell relatedcharacteristics determination and the group structure. The generation ofthe feedback report is based on the real time determination ofdistribution characteristics wherein said feedback report includesadditional information including for example the number of users towhich said feedback report applies. Said feedback report is sent to theserver being the multicast source, which utilizes the group feedbackreport by considering the percentage of the users for which saidfeedback report applies. The multicast/broadcast transmission is adaptedaccordingly to the utilized feedback report. Furthermore optionally theintermediate node makes proposal to the multicast source on how to adaptthe stream for the corresponding group of users, for example onlymultiple unicast is proposed if that's possible or handover overlay cellor other access network can be proposed. The reason for this is that theRNC, which can provide the intermediate node with certain data, may haveinformation, like for example radio characteristics of the cell area,that the source does not have and it may thus be in a better situationto judge how the stream could/should be adapted. As an example, RTCPcurrently indicates that the reception quality is not good, whichtriggers a source to go down with the bitrate to the next lower level.An RNC that determines an almost overloaded cell and many sessioninitiations per time unit could indicate that the bitrate has to bedecreased.

By receiving the aggregated feedback report the source utilizes theinformation included in the report considering the percentage of clientsfor which the feedback applies. The reaction can be to announce a newchannel to the clients or to adapt the stream, for example to reducebit-rate or to switch to more reliable codec.

To refrain the clients from sending RTCP Receiver Reports and generateRTCP receiver reports in an intermediate node, which hides the receiversof an entire cell. The intermediate node gets information from the RNCand creates a RTCP report from this. Additionally, RTCP packets withspecial wireless information can be used and filtered out at the RTCPgeneration node, which is the intermediate node.

Furthermore, optionally the RTCP report could contain in addition to thenumber of users the actual end-user addresses, since this may be ofinterest to the other users and/or the source.

In the following a description with respect to FIG. 4 is given.

FIG. 4 presents a protocol model for the present invention. It shows amulticast source, which sends the multimedia data to the clients bymeans of RTP Sender messages, not depicted in the figure. The protocolstack in the multicast source includes the RTP with the correspondingRTCP layer located above UDP and IP protocols. The L2 is a generaldescription for a link layer, which differs dependent on the network towhich the data is sent. A corresponding protocol stack is shown on thereceiver side, multicast receiver. However the link layer is specifiedfor the wireless network in this case it is the Radio Link Protocol withthe Radio Resource Control (RRC) protocol. According to the inventionthere is an intermediate network part located between the multicastsource and the multicast receiver, intermediate node. In the FIG. 4 thedifferent options for generation an aggregated feedback report arepresented.

It is possible that the intermediate node does not receive anyinformation from the clients. It means no RTCP reporting over the airinterface is available. The generation of RTCP feedback report isperformed from scratch in the intermediate node on the basis of thereceived RTP stream and potentially on Radio Resource Management RRMknowledge about a certain cell or area. For the purpose of receiving theRRM information the communication link, 10 is used. This information canbe either sent frequently or on the event-based basis. A report from theclients is not sent due to the fact that the client refrains fromsending RTCP reports on RTP/RTCP level or because all RTCP reports areblocked in the client's terminal.

In certain situations the client is allowed to send RTCP reports onunicast uplink channels, event-driven Reporting on the communicationlink between multicast receiver and the intermediate node. It means evenin cases when the report are refrained or blocked in the client'sterminal there is an option to send only RTCP reports with specialinformation, it means no regular RTCP reports are sent. Only in case ofextraordinary events, the RTCP reporting is done. In the case whenreport is refrained in the client's terminal this is handled on RTCPlevel. In case of blocked reports in the client, the terminal would haveto filter the regular RTCP reports. Which RTCP reports are regarded asextraordinary is service and access network dependent and may be subjectfor negotiation between the source and the destinations and/or betweenthe access networks and the destinations. For example an extraordinaryRTCP report can be generated when a loss rate excesses a certainthreshold. The RTCP reports are then used as additional input to form anaggregated RTCP message.

Another option of the invention is to refrain from sending RTCP reportsto all multicast receivers in order to maintain anonymity between theusers. Typically, users are also not interested in who is receiving theinformation as well. Additionally this option reduces the downlink loadin the network. Thus, RTCP reports except the Sender Reports are notsent in downlink direction. This option is not depicted in FIG. 4 sincethere is only one client shown.

In the following according to FIG. 5 an alternative for thedetermination of distribution characteristics associated with theclients is described.

The FIG. 5 depicts an alternative, logical architecture with clientscommunicating with the RNC. Further the communication path goes viaRadio and Core network to the so-called Service nodes in which theaggregated feedback message is generated considering the networkfeedback received from the RNC. It means the functionality of gettingthe necessary quality information at cell level that is physically splitfrom the node, which is compiling and sending the RTCP reports. No RTCPreceiver reports are sent from the mobile client. The service node canbe either a special node or a function implemented for example in GGSNor Multimedia Resource Function MRF wherein said service node outsidethe mobile core generates the RTCP receiver reports. RTCP receiverreports can be send per-RNC or per-cell.

Furthermore the provision of the per-cell or per-RNC RTCP reports alsoincreases the periodicity of quality feedback information and allows thesender to adapt faster to changing conditions. The RTCP reportinginterval can depend on the number of participants in the session.

In the following different detailed solutions for different scenariosare described in more details.

One of the possible scenarios is the broadcast scenario, which ischaracterized by a radio access set-up where no up-link is present. Thismeans that the multicast datagrams are sent in downlink direction, butno client response is sent back. The lack of a return channel prohibitsthat RTCP feedback is sent back from the clients. Although RTCP messagesmight be generated, there exist no medium to deliver these.

For the broadcast scenario the idea is that RTCP messages are generatedin a network node, for example in the RNC for WCDMA, which is basicallythe logical location for generating the RTCP reports. The new RTCPreceiver report is created based on radio related information.Therefore, the function of creating and sending an RTCP receiver reportand the data collection function can be split.

For the communication purpose the RTCP defines different RTCP messages.In the following one way of generating an aggregated message utilizingthe RTCP messages is described.

The RTCP defines Sender report (SR), Receiver report (RR), SourceDescription Items (SDES), Bye-Message (BYE), Application specificfunctions (APP). The messages can be bundled to form a so-calledcompound message. For the invention in particular the Receiver report(RR) is important, which needs to be received by the sender in order toadapt to changing bandwidth conditions. It is proposed that suchreceiver reports are generated in the RNC, based on the knowledge theRNC has about the link condition in one or more cells. The RNC cangenerate one message for each cell it is responsible for or even form asingle message for all.

In the following the different fields of a RR message are described asdefined in RFC 1884.

SSRC_n (source identifier) with 32 bits is the SSRC identifier of thesource, to which the information in this reception report blockpertains.

The field fraction lost with 8 bits describes the fraction of RTP datapackets from source SSRC_n lost since the previous SR or RR packet wassent, expressed as a fixed point number.

The field cumulative number of packets lost with 24 bits is the totalnumber of RTP data packets from source SSRC_n that have been lost sincethe beginning of reception.

For the field extended highest sequence number received 32 bits arereserved. The low 16 bits contain the highest sequence number receivedin an RTP data packet from source SSRC_n, and the most significant 16bits extend that sequence number with the corresponding count ofsequence number cycles.

There is also the interarrival jitter field with 32 bits. An estimate ofthe statistical variance of the RTP data packet interarrival time,measured in timestamp units and expressed as an unsigned integer. Theinterarrival jitter is defined to be the mean deviation (smoothedabsolute value) of the difference in packet spacing at the receivercompared to the sender for a pair of packets.

The field the last SR timestamp (LSR) with 32 bits describes the mostrecent RTCP sender report (SR) packet from source SSRC_n. If no SR hasbeen received yet, the field is set to zero.

The delay since last SR (DLSR) with 32 bits is a delay, expressed inunits of 1/65536 seconds, between receiving the last SR packet fromsource SSRC_n and sending this reception report block. If no SR packethas been received yet from SSRC_n, the DLSR field is set to zero.

The values for the entries in the RR need to be set for the purpose ofthe present invention to generate an aggregated feedback message.

The first field is simply the sender ID, which is known. For the secondfield, the fraction of lost packets, there are different alternatives.An appropriate value could be either the loss fraction seen by the RNC,or an estimate by the RNC depending on the current cell situation likefor example radio resource usage, interference, etc, and depending onthe reliability level chosen for the transmission in the cell.

Third field, the cumulative number of packet losses needs to be chosenaccording to the concept used for the previous field to avoid amismatch. For example, if the loss fraction is based on the packetlosses seen by the RNC, they should be used for this entry as well. Thehighest sequence number received should be the highest one the RNC hasseen. The interarrival jitter could be based on the jitter eitherobserved by the RNC, or by an estimated value taking the link parametersinto account for example whether ARQ or repetition coding or FEC areused to ensure a certain degree of reliability. The last SR timestampcan be taken without modification from the sender report received fromthe sender. In case the sender report has not been received yet, thefield is set to zero. The last field DLSR can remain either unmodifiedor a further improvement can be introduced. For example in order toprovide better round trip time RTT estimation for the sender, it isproposed to reduce the delay value by one radio access RTT. Further inorder to adapt the delay value to compensate for the access networkdelays, the delay value can be reduced for example by two RTT. Eventhough these are merely examples, which should not restrict the scope ofthe invention.

In the following a next scenario is presented, the multicast scenario.

The multicast scenario differs from the broadcast scenario mainly inthat a return channel is available. This as such would make end-to-endRTCP signaling possible, but because of problems indicated, namely theoverload of the radio resources when every client sends a report, it isproposed to generate the RTCP messages in the intermediate network part,preferably the RNC for WCDMA. In the following two currently possibleembodiments are described.

In the first embodiment in the client generated RTCP messages arediscarded in the client's terminal and generated from scratch in theintermediate node, like RNC. According to the RTP specification it iscurrently possible that the source indicates to the clients, that noRTCP receiver reporting shall be used. By receipt of this informationthe feedback messages in the clients are discarded or even notgenerated.

In the second embodiment it is foreseen that the generated RTCP messagesin the clients are transmitted over the radio interface to theintermediate network part, but modified in said network part accordingto certain principles described below. The RTCP message interval forRTCP messages from the client can be larger than the RTCP messageinterval for RTCP messages from the intermediate node to the sender. Theclient may even send RTCP messages only event driven, for example whencertain values are out of range.

The input for setting the different fields of the RR messages is thesame as for the broadcast scenario. Even though for the multicast thefollowing principles can be followed when setting the fields in the RRmessages. The first principle that could be applied is when using acommon transport channel in WCDMA, there will always be some receiverswith poor channel conditions suffering from large packet loss, whileothers get good quality. The RNC could in this case shield the poorreceiver reports to maintain quality for the good users. The secondprinciple can be applied if RNC detects an overload in a cell and wantsto reduce the bit rate on the common channel used formulticast/broadcast service, it can use the RTCP reports to signal thisto the Multicast server. This can be either by increasing the measuredpacket loss ratio in the reports, or just reducing the highest sequencenumber received. This will be quicker than end-to-end signaling becauseof the radio interface latency and since per user RTCP reporting becomesrare for large user groups.

In the following a general mechanisms are described which are common forthe above-described scenarios.

As already mentioned the aggregated RTCP feedback messages are generatedin an intermediate network part. In the above description the RTCPreport generation is done in the RNC. In general, this report generationand all related functionality is a logical function that could alsoreside in other network entities, such as the multicast/broadcastserver, the MB-SC. Dedicated protocols could be used to forward therelevant information from the RNC to the MB-SC in that case.

In a preferred embodiment of the present invention the user anonymity isto be guaranteed. Different from some Multicast applications in thefixed Internet like audio and video-conferences, mobile users formtypically an anonymous community. Users in mobile networks which look atthe same video clip are most likely not interested in knowing the namesof other viewers and might also not be interested in revealing theiridentity. The RTCP messages, in particular the RR and SDES messagesaccording to the standard should include the identity of users forexample in the format of an email-address. Thus, the invention proposesto transmit the RTCP messages, which are generated in the intermediatenode, only back to the RTP stream sender.

Together with the generation of an aggregated RTCP report, the number ofdestinations for which the RTCP report applies is added to the report.This information is then potentially considered by the source in case ofmulticast stream adaptations. It means if an aggregated RTCP reportcovers thousands of destinations, the source could adapt for thesedestinations. If it covers only ten destinations in a session wherethousands of destinations are involved, it may be better to advise theclients to switch to a unicast session instead.

In the following two embodiments of the present invention are disclosed.In the first one an aggregated feedback message is generated in theintermediate node based on the RTCP reports per mobile terminal asdisclosed according to FIG. 6.

FIG. 6 depicts a multicast source sending RTP flow, downstream-multicasttraffic via an intermediate node and the corresponding RNCs to theclients with their mobile terminals. The intermediate node generatesRTCP receiver reports and sends these as feedback to the multicastsource. Said feedback is generated considering the user and cellinformation received from the RNC.

To distinguish between several multicast sources, each receiver report(RR) packet is addressed by the SSRC of the source. Therefore, theintermediate node must process and forward the downstream-multicasttraffic from the source to the receivers and extract the SSRC of theMulticast Source. The SSRC is necessary to address the upstream RTCPreceiver report packets, which are generated in the intermediate node.The number of mobile terminals per cell plus reception conditions perterminal is provided by the RNC.

The intermediate node must allocate an SSRC identifier for each client'sterminal. The intermediate node must allocate the SSRC on behalf of eachclient's terminal. Beside the SSRC, the intermediate node must alsoprovide a SDES CNAME item for each client. There are several options ofchoosing the CNAME for a particular user. In case of anonymousparticipation, when the source shall not get a clear CNAME, the SDESCNAME item is randomly chosen. It can be for example in form of<random-number>@host. The CNAME must be unique. In case of anon-anonymous CNAME, either the operator predetermines the user name forexample phonenumber@domain or the user specifies the CNAME in apreference database. Therefore, the intermediate node must maintain alist of client's terminals per cell plus the associated SSRCs allocatedby the intermediate node and CNAMEs. The intermediate node functionalityis possibly included in the BM-SC or the GGSN. The content of each RTCPpacket is created like described in the previous chapters.

In case the very large user group, which is spread over a very largenumber of cells, the Intermediate node shall send RTCP packets not perclient but per cell. It is very likely, that each cell servers anapproximately equal number of group members. This embodiment isdisclosed in FIG. 7, which depicts coincident facts as in FIG. 6. Thedifference is that the intermediate node generates a feedback messageper cell.

In this case, the Intermediate node allocates valid SSRCs and CNAME foreach cell, which contains group members. The number of send RTCP packetsis decreased. The transmission interval of RTCP packets and thereforealso the reaction time of the multicast source decreases by sendingper-cell RTCP packets.

As an additional RTCP packet type can be introduced into to weight theRTCP receiver report to the number of users in the cell. This RTCPpacket type must part of a RTCP compound packet whenever this RTCPpackets contains receiver reports for more than one member.

The present invention delivers a solution for wireless and multicastspecific RTCP reporting taking the specifics of wireless networks intoaccount and improving the overall service quality. Other informationfrom lower layer protocols as already known in the RNC, can beconsidered in the reports to further optimize the service quality.However, it is just one part of the invention to forward additionalradio related info to the source. Another one is that the RNC considersthe info and makes an adaptation proposal to the source. With this thesource does not need to have info about the radio network, since it isthe radio network that converts this info to a known adaptation proposalfor the source.

1. A method b adapting multi-user multimedia data in a communicationnetwork, with a server providing the multi-user multimedia data to agroup of clients, comprising the steps of: providing information ondistribution characteristics to an Intermediate network part between theserver and the group of clients, wherein the intermediate network partis a functionality implemented in one or more nodes; sending a datastream, via the intermediate network part containing the multi-usermultimedia data from the server to the group of clients; determiningreal time distribution characteristics, regarding the data stream,associated with the group of clients; generating a feedback report onthe group of clients'reception conditions of the data stream,considering the distribution characteristics, said feedback reportcomprising a client group structure and an aggregation of the real timedistribution characteristics of all clients in the group includingInformation about aggregation technique and manner of adaptation;Suppressing a portion of the feedback report in the network terminals;sending the feedback report to the server; and adapting transmission ofthe data stream from the server to the group of clients according to thefeedback report.
 2. The method according to claim 1, wherein thedistribution characteristics are related to a geographical areaincluding a group of clients.
 3. The method according to claim 2 whereinthe geographical area is covered by one or more cells in a wirelesscommunication network.
 4. The method according to claim 1 wherein thedistribution characteristics are related to a determined multicast groupstructure.
 5. The method according to claim 1 wherein the distributioncharacteristics are related to information received from a radioresource management.
 6. The method according to claim 5 wherein theinformation received from the radio resource management is sent eitherfrequently or event-based.
 7. The method according to claim 1 whereinthe distribution characteristics are related to information receivedfrom the group of clients.
 8. The method according to claim 7 whereinthe information received from the group of clients is sent eitherfrequently or event-based.
 9. The method according to claim 1 whereinthe suppressed portion of the feedback report comprises RTCP feedback.10. The method according to claim 1 wherein the information receivedfrom the group of clients impacts information from the radio resourcemanagement.
 11. The method according to claim 1 wherein the informationabout aggregation technique includes a number of clients to which thefeedback report applies.
 12. The method according to claim 1 wherein theadditional information about aggregation technique comprises radiocharacteristics of an access network in which the clients are.
 13. Themethod according to claim 6 wherein a negotiation on the frequency offeedback reports from the clients or from the radio resource managementto the intermediate node is performed.
 14. The method according to claim1 wherein the terminals refrain from sending feedback reports to otherterminals receiving the data stream.
 15. The method according to claim 1wherein the generated feedback report includes a fraction of lostpackets provided by the intermediate node depending on the currentconditions of delivery, a highest sequence number the intermediate nodehas received, and an inter-arrival jitter provided by the intermediatenode.
 16. The method according to claim 1 wherein by receiving thefeedback report the source utilizes the information included in thereport considering the percentage of the clients for which said feedbackapplies wherein the stream is adapted to reduce bit rate or switch to amore reliable codec.
 17. The method according to claim 1 wherein thegeneration of the feedback report and the determining of distributioncharacteristics associated with the clients are performed in a same nodebeing the intermediate network part or are split between different nodesforming the intermediate network part.
 18. The method according to claim1 wherein the transmission of data stream is performed by means of RTPhaving a control protocol RTCP for reporting feedback.
 19. Anintermediate network part for adapting a multi-user data stream in acommunication network with a server providing the multi-user data streamto a group of clients, the intermediate network part being Implementedin one or more nodes and arranged to provide information on distributioncharacteristics between the sewer and the group of clients and whereinsaid intermediate network part comprises: means for forwarding the datastream from the server to the group of clients; means for determining ofthe distribution characteristics associated with the group of clients;means for generating a feedback report on the group of clients'receptionconditions of the data stream considering the distributioncharacteristics, said feedback report including a client group structureand an aggregation of the real time distribution characteristics of allclients in the group including information about aggregation technique,and manner pf adaptation; means for suppressing a portion, comprisingRTCP feedback, of the feedback report in the network terminals; andmeans for sending the aggregated feedback report to the server.
 20. Theintermediate network part according to claim 19 having all the meansimplemented in a same network node.
 21. The intermediate network partaccording to claim 19, wherein the means for determining distributioncharacteristics associated with the group of clients and the means forgenerating an aggregated feedback report are each incorporated indifferent nodes.
 22. The intermediate network part according to claim 21having means for receiving the external determined distributioncharacteristics associated with the group of clients.